Service virtual machine

ABSTRACT

Technology is disclosed for processing in a computer program a request received by a service virtual machine (SVM). The technology can receive a request in either a first form or a second form, wherein the first form includes a target textual identifier, a reply-to textual identifier, and a parameter, and the second form includes a target textual identifier and a parameter, but not a reply-to textual identifier; identify, based on the received target textual identifier, a procedure; invoke the identified procedure and providing a value of the received parameter to the invoked procedure; in an event the received request is in the first form: receive a result from the invoked procedure; form a reply-to request in the second form, the second form including as a target textual identifier the reply-to textual identifier in the received request, and as a parameter the result received from the invoked procedure, further wherein the second form does not include a reply-to textual identifier; and send, to the SVM, the formed reply-to request.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This patent application is a continuation of U.S. patent applicationSer. No. 14/292,721, filed on May 30, 2014, which is acontinuation-in-part of U.S. patent application Ser. No. 12/135,879,entitled ACTOR VIRTUAL MACHINE, filed on Jun. 9, 2008, each of which isincorporated herein in its entirety by reference.

BACKGROUND

Programming languages that support imperative programming (e.g., C andPascal) can organize code into procedures. A procedure has a name and abody. The name of a procedure serves as a hardcoded reference to theprocedure, and the body of a procedure contains a sequence of programinstructions (e.g., statements). Procedures are invokable (also referredto as callable). A procedure being invoked may take a number ofparameters (also referred to as arguments) from a caller as input andreturn one or more results back to the caller as output. Inputs andoutputs are optional. The caller can be the same procedure (as inrecursion), a different procedure, or even another type of programmingunit (e.g., an unnamed code block). To invoke a procedure, a caller usesa calling statement, in which the caller specifies a reference to thetarget procedure, which can be the name of the target procedure, andprovides arguments as required by the target procedure.

Programming languages that support objects (e.g., Java, JavaScript, C#,and C++) can further organize procedures into objects. To invoke aprocedure in an object, a caller has to specify an extra reference in acalling statement in addition to a reference to the target procedure;this extra reference is a reference (also known as a pointer) to thetarget object. Aside from this, passing input parameters to andreceiving return values from a procedure in an object are the same aswith standalone procedures.

In different programming languages, a procedure may be called afunction, a routine, a subroutine, or a subprogram. A procedure that isnot associated with or provided by another programming unit can becalled a standalone or global procedure. In programming languages thatsupport objects, a procedure that is associated with or provided byanother programming unit (e.g., an object, a class, a prototype) canalso be called a method.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a call invocation diagram illustrating a calling statementthat invokes a procedure in a program that supports procedures.

FIG. 1B is a call invocation diagram illustrating a calling statementthat invokes a method in an object in a program that supports objects.

FIG. 2A is a call invocation diagram illustrating an SVM and a servicethat are implemented in a language that supports procedures.

FIG. 2B is a call invocation diagram illustrating an SVM and a servicethat are implemented in a language that supports objects.

FIG. 3 is a call flow diagram illustrating a first sample SVMimplemented as an object in a language that supports objects.

FIG. 4 is a call flow diagram illustrating the logic a source SVM thatreceives a request can use to determine how to forward the request toits target SVM in the same SVM network.

FIG. 5 is a call flow diagram illustrating how to invoke local anddistributed services.

DETAILED DESCRIPTION

Technology is described for implementing and using a service virtualmachine (“SVM”). In various embodiments, an SVM can be a nativeprocedure or object in a computer program that translates invocation onvirtual programming units to invocation on native programming units withvarious add-on features. In various embodiments, virtual programmingunits can serve as interfaces for native programming units.

As used herein, the term “native” refers to programming units (e.g.,procedures, methods, objects) that are directly supported by syntaxand/or runtime libraries or other logic of an underlying programminglanguage. This contrasts with virtual programming units (e.g., virtualprocedures, virtual methods, virtual objects), which are not native tothe underlying programming language and are supported by an SVM. Virtualprogramming units are bodiless programming units that only have textualidentifiers (“IDs”) that can serve as references to the virtualprogramming units.

Turning now to the Figures, FIG. 1A is a call invocation diagramillustrating a calling statement that invokes a procedure in a programthat supports procedures. A caller uses a calling statement 102(“functionA (args)”) that specifies only a reference (functionA) to thetarget procedure 104.

FIG. 1B is a call invocation diagram illustrating a calling statementthat invokes a method in an object in a program that supports objects. Acaller uses a calling statement 106 (“objectA.methodA (args)”) thatspecifies a reference (objectA) to a target object 108 and a reference(methodA) to the target method in the target object 108.

In various embodiments, SVMs build an abstraction layer above underlyinglanguages (and their runtime code) to support virtual programming units,e.g., virtual procedures. Virtual procedures have Procedure IDs, whichcan serve as references to the virtual procedures.

In various embodiments, an SVM can implement a virtual procedure byassociating it with a native procedure. Thus invocation of a virtualprocedure causes invocation of the associated native procedure. A callercan invoke a virtual procedure by submitting a request (which is datasuch as a message) to an SVM that hosts the virtual procedure. In therequest, the caller specifies a Procedure ID to reference the targetvirtual procedure. The caller may also provide arguments in the requestas required by the target virtual procedure.

FIG. 2A is a call invocation diagram illustrating an SVM and a virtualprocedure that are implemented in a language that supports procedures.The SVM is implemented as a native procedure svmFunction ( )208. Thevirtual procedure 206 has a Procedure ID “PlaceOrder”. To invoke thevirtual procedure 206, a caller creates a request and submits therequest to the SVM 208 by using a calling statement 202. The request,which is in form of arguments in the calling statement 202, specifies“PlaceOrder” as a reference to the virtual procedure 206. The SVM 208processes the received request by interpreting the request, identifyingthe virtual procedure 206 as the target, and invoking the nativeprocedure functionA ( )204 that is known by the SVM 208 as associatedwith the virtual procedure 206.

FIG. 2B is a call invocation diagram illustrating an SVM and a virtualprocedure that are implemented in a language that supports objects. TheSVM is implemented as a native object svm 218. The virtual procedure 216has a Procedure ID “PlaceOrder”. To invoke the virtual procedure 216, acaller creates a request and submits the request to the SVM 218 by usinga calling statement 212. The request, which is in form of arguments inthe calling statement 212, specifies “PlaceOrder” as a reference to thevirtual procedure 216. The SVM 218 processes the received request byinterpreting the request, identifying the virtual procedure 216 as thetarget, and invoking the methodA ( ) in the native object objectA 214that is known by the SVM 218 as associated with the virtual procedure216.

In various embodiments, virtual programming units can be built into ahierarchy. A virtual object can be created by containing a number ofvirtual methods. A virtual object has an Object ID and a virtual methodhas a Method ID. A virtual object can be identified by its Object ID buta virtual method cannot be identified by its Method ID alone. Instead, avirtual method can be identified by its owning Object ID and its MethodID due to the hierarchical relationship.

In order to invoke a virtual programming unit, a request can contain afull reference to specify the target virtual programming unit. For avirtual procedure, a Procedure ID is its full reference. For a virtualobject, an Object ID is its full reference. For a virtual method, whichis in a lower part of a hierarchy, its owning Object ID and its MethodID together make its full reference. A virtual programming unit can bereferred to as a virtual service (or simply a service), and a fullreference to a service can be referred to as a Service ID. In variousembodiments, an SVM can accept a Service ID in various formats andmanipulate it into other formats (e.g., accept a one-piece ID and breakit into smaller IDs, accept smaller IDs and combine them into aone-piece ID, accept an encoded Service ID and decode it).

In various embodiments, an SVM can implement a virtual programming unitby associating it with a callable native programming unit. An SVM canassociate a virtual programming unit with a callable native programmingunit regardless of their types and hierarchies (e.g., a virtualprocedure may associate with a native procedure, a virtual method mayassociate with a native method, a virtual procedure may associate with anative method and vice versa, and a virtual object itself may evenassociate with a native procedure or method, etc.).

An SVM can support a reply-to feature for a request that contains areply-to Service ID in addition to a target Service ID. For such arequest, an SVM will collect return values from invoked nativeprogramming unit in processing the request and form a reply-to request.The reply-to request contains a target Service ID, which is the same asthe reply-to Service ID in the current request, and parameters, whichare the collected return values.

FIG. 3 is a calling flow diagram illustrating a first sample SVMimplemented as an object in a Java-like pseudo language. The firstsample SVM is implemented as a native object svm 322 that works as astandalone SVM. A standalone SVM processes all received requests anddoes not consider forwarding requests for other SVMs.

The SVM 322 supports a virtual object “order” 324 containing threevirtual methods “place”, “pay”, and “pickup”. The SVM 322 chooses not todecode their Service IDs into Object IDs and Method IDs, but insteadhardcodes the associations between these virtual methods and nativemethods. The virtual methods “order.place” and “order.pay” areassociated with the methods actionA ( ) and actionB ( ) respectively, ina native object sales 326. The virtual method “order.pickup” isassociated with the method actionC ( ) in a native object shipping 328.

A caller uses a calling statement 320 to submit a request by invoking amethod, call ( )323, provided by the SVM 322. The request contains atarget Service ID “order.place”, an array of parameters (“computer” as aproduct code, and 1 as quantity), and a reply-to Service ID “order.pay”.

The call ( )323 invokes the actionA ( ) in the native object sales 326that is associated with the Service ID “order.place” according to thesource code. Since the ReplyTolD is not null (“order.pay” is provided asthe ReplyTolD in the request), the call ( ) 323 forms a reply-to requestand submits it as a new request. In various embodiments, an SVM canhandle any error that happens during the processing of requests bylogging errors (e.g., in a local log file).

An SVM can provide other means in addition to a local API (e.g., amethod, a procedure) to receive requests from local and distributedcallers. Such means may include socket connections, queues, messagingservices, databases, etc., to which callers can submit requests. Localcallers of an SVM are callers that are in the same program with the SVM.Distributed callers are callers in other programs that can be running onother computers (and can even be written in other languages). Any meansthrough which an SVM receives requests can also be referred to as achannel of the SVM for submitting requests. A channel can be directlyprovided by an SVM (e.g., a local API) in a dedicated fashion, asrequests submitted to such a channel will be only received by the SVM. Achannel may also be supported by an SVM (e.g., a messaging system). Sucha channel may be shared by multiple SVMs, each of which can accesssubmitted requests; however doing so may create ambiguity about whichSVM should pick up a particular request. If a shared channel isunavoidable, ambiguity in picking up requests may be resolved bydedicating a unique textual SVM ID to every SVM with access to theshared channel and by using the SVM ID in every request for the intendedreceiving SVM through such a channel.

Two SVMs that have unique textual SVM IDs can be connected to each otherand send requests to each other directly through their channels.Connected SVMs are called neighbors of each other. A term “SVMconnection” (or simply “connection”) describes the status of twoconnected SVMs. It does not refer to particular channels, but ratherrepresents a functional connectivity between the SVMs.

A group of interconnected SVMs can form a network of SVMs (also referredto as an SVM network). An SVM network can be used to transfer a requestfrom a source SVM to a target SVM through intermediate SVMs between thesource and the target. Each intermediate SVM receives the request fromone of its neighbors and sends the request to another neighbor until therequest eventually reaches the target SVM. The series of intermediateSVMs the request passes through in sequence is called a route or pathbetween the source and target SVMs.

FIG. 4 is a call flow diagram illustrating the logic a source SVM thatreceives a request can use to determine how to forward the request toits target SVM in the same SVM network. When an SVM receives a request,the SVM performs a first check 402 to see whether the request contains atarget SVM ID. If it does not, the SVM processes the request. If itdoes, the SVM performs a second check 404 to see whether the target SVMID matches its own SVM ID. If it does, the SVM processes the request. Ifit does not, the SVM performs a third check 406 to see whether thetarget SVM is one of its neighbors. If it is, the SVM sends the requestto the identified neighbor. If it is not, the SVM performs a fourthcheck 408 to see whether the request contains valid routing informationthat indicates one of its neighbors is in or stores a route to thetarget SVM. If such routing information is found, the SVM sends therequest to the identified neighbor. If such routing information is notfound, the SVM performs an action 410 to seek routing information thatindicates one of its neighbors is in or stores a route to the target SVMinternally (e.g., performing its owning routing to generate routinginformation for the request, reading a routing table in memory or from aconfiguration file) and/or externally (e.g., contacting other SVMs orrouters). If such routing information is still not found after seeking,the SVM handles the request as an error (e.g., discards the requestsilently, logs the request with error messages, sends the request to apredefined administration SVM). If such routing information is foundafter seeking, the SVM sends the request to the identified neighbor.

FIG. 5 is a call flow diagram illustrating how to invoke local anddistributed services. A JavaScript program 510 includes an SVM svm1 (SVMID “svmA”) 514, a virtual object “order” 515, and a virtual procedure“refund” 516. A Java program 520 includes an SVM svm2 (SVM ID “svmB”)524, a virtual object “product” 525, and a virtual procedure “recycle”526. A C# program 530 includes an SVM svm3 (SVM ID “svmC”) 534, a firstvirtual procedure “replace-product” 535, and a second virtual procedure“return-product” 536. The svm1 514 and the svm2 524 are connectedneighbors; the svm2 524 and the svm3 534 are also connected neighbors.

When the svm1 514 receives a request, the svm1 514 can use the logicdescribed in FIG. 4 to determine how to process or forward the request.The svm1 514 will process a request 511 as its target SVM ID “svmA”matches the SVM ID of the svm1 514. The svm1 514 accepts a Service IDcontaining an Object ID and a Method ID that are separated by a dot.

The svm1 514 will forward a request 512 to the svm2 524 as its targetSVM ID “svmB” matches the SVM ID of the svm2 524. The svm2 524 willprocess the request 512. The svm2 524 accepts a Service ID containing anObject ID and a Method ID that are separated by a hyphen.

The svm1 514 will forward a request 513 to the svm2 524 if the svm1 514knows that the svm3 534 can be reached through the svm2 524. The svm1514 can learn this knowledge by having it hardcoded, loading it from aconfiguration file, performing routing, etc. Similarly, the svm2 524will forward the request 513 to the svm3 534, which will process therequest 513. The svm3 534 accepts a Service ID as is, without breakingit into smaller IDs.

An SVM operates “on top of” a high-level programming language. Thismeans an SVM can uses advanced features provided by an underlyinglanguage. An SVM can use type introspection to determine the type orproperties of an identified native object. If the native object is of aknown type, the SVM can typecast it to that type and perform knownoperations on it (e.g., invoke known methods on the type). An SVM canuse reflection to obtain a reference to a method in a native object byits textual name and use the reference to invoke the method. With thereflection feature, an SVM can associate methods in a native object tovirtual programming units without the native object being aware of theassociate and participation of SVM.

An SVM can use multi-threading to receive a request and invoke atargeted native programming unit asynchronously. This helps an SVMprocess a large number of requests received in a short time period in astable order (e.g., first-come, first-served). An SVM can still achievesynchronism between receiving requests and invoking targeted nativeprogramming units on an underlying language that does not providemulti-threading but supports independent thread scheduling (e.g.,JavaScript). A same thread that appears at the same place in the code atdifferent times due to independent thread scheduling can be viewed asdifferent threads. An SVM can provide various add-on features in theprocessing of requests at multi-threaded runtimes. An SVM can processconcurrent requests that target a same native object in a sequentialmanner. Thus methods in the native object will only be invoked by onethread at a time. This provides the native object with a single-threadedenvironment. An SVM can associate a virtual programming unit withmultiple native objects, each of which can carry out a request by athread. Thus concurrent requests that target the same virtualprogramming unit can be carried out concurrently by these multiplenative objects.

FIG. 6 is a source code listing for a second sample SVM that illustrateshow to provide add-on features for processing requests by utilizingadvanced features provided by underlying languages. Source code (below)provides additional details.

The second sample SVM is an object of the JavaSVM class, which is shownat Line 9-142 (see source code below). The second sample SVM provides amethod registerObject ( )(as shown at Line 25-27) to receiveassociations (as shown at Line 25) for creation of new virtual objects.All associations are stored in a variable called associationMap (asshown at Line 12) from which an association can be retrieved by itsunique Object ID.

An association contains an Object ID, one or more associated nativeobjects, and instructions that can customize the processing of requeststhat target the virtual object. According to these instructions (asshown at Line 14-24), an association is not required to define virtualmethods. The second sample SVM will locate a method in a native objectin a way specified by the method policy.

The association should provide a MethodPolicy. The second sample SVMsupports two method policies: “same-name” and “java-interface”. Themethod policy “same-name” instructs the second sample SVM to look for amethod in a native object based on the Method ID in a request. Thesecond sample SVM employs the reflection feature provided by Javalanguage runtimes to perform the lookup (as shown at Line 45-50). As aresult, a native method whose textual method name is the same as theMethod ID is identified and used for invocation (as shown at Line110-112). The method policy “java-interface” instructs the second sampleSVM that a native object is an instance of a known HandlerInterface (asshown at Line 144-146). Thus the second sample SVM will typecast thenative object to the HandlerInterface and invoke a known method,onRequest ( )(as shown at Line 113-116).

The association should provide a ThreadPolicy. The second sample SVMsupports four thread policies: “thread-pool”, “GUI-thread”,“single-threaded” and “load-balancer”. A thread policy instructs thesecond sample SVM to use a specific thread in a specific way to invoke amethod in a native object. The thread policy “thread-pool” instructs thesecond sample SVM to use a thread from a thread pool (as shown at Line11) to invoke a native method (as shown at Line 57-62). The threadpolicy “GUI-thread” instructs the second sample SVM to use the JavaSwing thread to invoke a native method (as shown at Line 63-68). Thethread policy “single-threaded” instructs the second sample SVM to use athread from the thread pool to invoke a native method such that only onethread can invoke a method in a native object at a time even if thereare multiple concurrent requests targeting the same native object (asshown at Line 69-80). The thread policy “load-balancer” instructs thesecond sample SVM to first choose a native object that is not currentlybeing invoked from all native objects that are associated with the sameObject ID; then the second sample SVM uses a thread from the thread poolto invoke a method on the chosen native object (as shown at Line81-100).

The association should provide one or more NativeObjects to beassociated with the virtual object. The number of native objects isdetermined by the thread policy. For method policies “thread-pool”,“GUI-thread” and “single-threaded”, one native object is needed. Formethod policy “load-balancer”, a number of native objects are needed, asthe second sample SVM needs a pool of native objects to performload-balancing.

The association should provide zero or more NativeLocks. Locks are usedto ensure that only one thread can invoke a method in a native object ata time. This feature provides protection to a native object such thatall methods in the native object can be coded in single-threadedfashion. The number of native objects is determined by the threadpolicy. For the thread policy “thread-pool”, locks are not needed andnative objects should handle multi-threading on their own. For thethread policy “GUI-thread”, locks are not needed as the Java Swingthread is a single thread. For the thread policy “single-threaded”, onelock is needed as there is one native object in this case. For thethread policy “load-balancer”, a number of locks are needed such thateach native object is protected by a lock.

The second sample SVM provides a method invokeService ( )(shown at Line29-39) to receive and process requests that invoke virtual services. Arequest contains a target Service ID, a reply-to Service ID, and anumber of parameters. The invokeService ( ) prepares to process areceived request by creating a temporary variable called session thatstores all intermediate data produced and shared by all steps ofprocessing, decoding the target Service ID into an Object ID and aMethod ID, and retrieving an association by the decoded Object ID (asshown at Line 30-36).

With the identified virtual object and association, the invokeService () continues to process the request by carrying out the method policy andthread policy specified in the association (as shown at Line 37-38). Thesecond sample SVM provides a method, identifyNativeMethod ( )(as shownat Line 41-54), to carry out method policy. The identifyNativeMethod ( )locates both a target native object and a target native method andstores them into the session for next steps. If the method policy in therequest is “java-interface”, the identifyNativeMethod ( ) locates atarget native object only, as the target native object is an instance ofa known interface Handlerinterface.

The second sample SVM provides a method, identifyThreadAndlnvoke ( )(asshown at Line 56-102), to carry out thread policy. TheidentifyThreadAndlnvoke ( ) is responsible for choosing a threadspecified by the thread policy in the request and submitting the targetnative method to the identified thread for execution. The second sampleSVM provides another method, invokeAndReply ( )(as shown at Line104-126), to invoke the target native method.

This design ensures that target native methods are executedasynchronously. When a caller submits a request to the SVM at theinvokeService ( ) the caller's thread steps into the invokeService ( )and executes codes there, and the caller's thread continues through theidentifyNativeMethod ( ) and the identifyThreadAndlnvoke ( ) In otherwords, the processing of requests is actually performed by the caller'sthread. The identifyThreadAndlnvoke ( ) stops the caller's thread byswitching the thread context for invoking of the target native method(as shown at Line 58, 64, 70 and 82).

For the thread policy “thread-pool”, the identifyThreadAndlnvoke ( )simply submits the invokeAndReply ( ) to a thread from the thread pool(as shown at Line 57-62). For the thread policy “GUI-thread”, theidentifyThreadAndlnvoke ( ) submits the invokeAndReply ( ) to the JavaSwing thread (as shown at Line 63-68). For the thread policy“single-threaded”, the identifyThreadAndlnvoke ( ) submits theinvokeAndReply ( ) to a thread from the thread pool with extra logics(as shown at Line 69-80). The extra logics ensure that only one threadcan invoke a method in the target native object at a time. For threadpolicy “load-balancer”, the identifyThreadAndlnvoke ( ) submits theinvokeAndReply ( ) to a thread from the thread pool with extra logics(as shown at Line 81-100). The extra logics can detect whether anotherthread is currently executing a method in a target native object so thatthe logics can identify a target native object that is available foruse.

As a last step, the invokeAndReply ( ) receives the identified nativeobject and the parameters in the request (as shown at Line 106-107) anddecides to invoke the native object either using reflection (as shown atLine 110-112) or through typecasting (as shown at Line 113-116) based onthe method policy. In either case, the invokeAndReply ( ) collectsreturn values from the invoked method in the native object. If therequest specifies a reply-to Service ID, the invokeAndReply ( ) forms areply-to request that contains the collected return values and submitsit to the SVM at the invokeService ( )(as shown at Line 119-122).

A reply-to request carries return values from a preceding request andtargets a virtual service which can be the caller, if it is a virtualservice, or other virtual service. In order for a conventionalnon-service caller to receive results from a virtual service the callerjust called, the caller can use a helper called token to retrieveresults. A token is an object of the Token class (as shown at Line148-185) and offers three typical usages to retrieve its results: thecaller can register a listener (as shown at Line 182) and be notifiedwhen results are available; the caller can query a non-block method,isReady ( )(as shown as Line 171), to check whether results areavailable; or the caller can wait for results by invoking a blockmethod, getResult ( )(as shown at Line 175). The second sample SVMprovides a method, createNewToken ( )(as shown at Line 128-141) tosimplify the usage of a token. A simple code snippet that illustratesusage of the createNewToken ( ) and a token is shown at Line 188-191.

Routing is the process of identifying and selecting routes in an SVMnetwork. An SVM can use a neighbor table to store all of its neighborsand their channel information. Thus the neighbor table can be used todetermine whether a given SVM is a known neighbor and to retrievechannel information for sending requests to that neighbor. An SVM canuse a routing table in addition to a neighbor table to assist inperforming routing for received requests. A routing table may contain anentry for each target SVM that contains route information for how toreach the target SVM. Route information can be as complete as a fullroute to the target SVM, or as simple as a neighbor who may figure outthe rest of the path, or anything in between.

When an SVM receives a request, it checks its routing table for thetarget SVM of the request. If an entry is found, the SVM inserts theroute found in the entry into the request and passes the request to theneighbor specified by the route, which is the first intermediate SVM inthe route. Every intermediate SVM in the route skips performing its ownrouting and passes the request to the neighbor specified by the route,which is a next intermediate SVM in the route.

If the end of the given route is the target SVM, then the given route isa full route to the target SVM. This is referred to as source routing.If the end of the given route is not the target SVM, then the givenroute is only a partial route to an intermediate SVM, referred to as anext hop, which is prior to the target SVM. The hop acts as a new sourceSVM and performs its own routing for the request towards the target SVM.This process may be repeated until the request reaches the target SVM.This is referred to as hop-by-hop routing.

A routing table can be established from source code or configurationfiles, and needs to be updated based on network changes that impactrouting, such as SVMs that have joined, SVMs that have left, connectionsthat have been established, and connections that have been destroyed.SVMs can update their routing tables by reloading configuration filesfrom time to time, as a network administrator may update thoseconfiguration files based on new network changes. Or SVMs can reportnetwork changes they are aware of to each other. Thus SVMs in an SVMnetwork can automatically learn of network changes in a real-timefashion. SVMs that exchange network changes and other routinginformation can employ routing algorithms and protocols such aswell-known link-state and distance-vector routing protocols.

An SVM can manage local virtual services (e.g., play the role of an SVMhost), perform routing (e.g., play the role of an SVM router), or doboth. It also allows an SVM to play only one role. An SVM host canconnect to and have an agreement with an SVM router in the same SVMnetwork. The SVM host performs no routing and all requests (received byor generated inside the SVM host) targeting other SVMs are passed to theSVM router. The SVM router reports network changes (e.g., related to theSVM host) to other SVM routers, receives requests targeting the SVMhost, and passes such requests to the SVM host.

Two SVM networks are connected if at least one SVM router from each sideis connected to the other. A group of interconnected SVM networks canform a large SVM network provided that all SVM IDs are unique within thelarge SVM network. A large SVM network can be used to transfer a requestfrom a source SVM in a first SVM network to a target SVM in a second SVMnetwork. Every request that needs to be routed contains a target SVM ID.In an SVM network or a network of SVM networks that contains a massivenumber of SVMs, each target SVM ID is expected to carry extrainformation for assistance of locating a target SVM.

Using naming conventions (e.g., Domain name naming convention, Javapackage naming convention) can create hierarchical SVM IDs foruniqueness and organizing SVMs. In this document, Java package namingconvention is used for illustration purpose. This convention uses atextual section to represent a hierarchical layer, uses dots to separatelayers, and places the most top layer on the most left side (e.g.,“us.wa.seattle” and “ca.bc.vancouver” are two examples).

SVMs with IDs that belong to a same layer can be placed into a same SVMnetwork, which uses the common ID prefix as its network ID prefix. Forexample, SVMs with IDs that match “us.wa.seattle.*” can be placed into afirst SVM network which uses the ID prefix “us.wa.seattle”. SimilarlySVMs with IDs “us.wa.bellevue.*” can be placed into a second SVM networkwith ID prfix “us.wa.bellevue”. When a first SVM router in the first SVMnetwork “us.wa.seattle” receives a request with a target SVM ID“us.wa.bellevue.Alpha”, the first SVM router can easily know the targetSVM is in an SVM network with ID prefix “us.wa.bellevue”. If the firstand second networks are connected, the first SVM router can send therequest to a second SVM router in the second SVM network“us.wa.bellevue” (assuming these two SVM networks are connected viathese two SVM routers). If the first and second networks are notconnected, the first SVM router can send the request to its parent SVMnetwork “us.wa”, which connects to all child SVM networks including theSVM network “us.wa.bellevue”.

Routing requests through hierarchical structure should be treated as thelast resort rather a first choice. An SVM network can directly connectto any other SVM networks. A request from the SVM network“us.wa.seattle” targets an SVM “ca.bc.vancouver.Zulu” can be routeddirectly to the SVM network “ca.bc.vancouver”, if connected, rather thanbe routed through SVM networks “us.wa”, “us”, “ca”, “ca.bc”, and“ca.bc.vancouver”.

An SVM network can have more than one ID prefix. The first and secondSVM networks “us.wa.seattle” and “us.wa.bellevue” above can be mergedinto a single SVM network with two ID prefixes.

A large number of SVM networks can also be organized in the structure ofthe Internet. An SVM host or router is analogous to a host or routerrespectively in the Internet and an SVM ID is analogous to a domainname. Similarly every SVM ID can be assigned and mapped to an IP addressthus SVMs are grouped into SVM networks based on hierarchy of their IPaddresses rather than of SVM ID and use IP prefixes rather than SVM IDprefixes. Each SVM network is analogous to an autonomous system in theInternet and can be assigned a globally unique Autonomous System Number(ASN). As a result, all SVM networks are able to use exterior gatewayprotocols such as Border Gateway Protocol (BGP) to share routinginformation among them.

In the context of a standalone SVM, all requests are received andprocessed by such an SVM, as in this case the standalone SVM is bydefinition the receiving SVM and the target SVM. In such a case, callersmay not need to specify the receiving SVM ID or the target SVM ID. Whenusing a shared channel of the SVM, a caller may need to specify areceiving SVM ID. In the context of one or more SVM networks, a callermay submit a request to a receiving SVM while specifying a differenttarget SVM. In this case, the caller must specify the target SVM ID, asa request without a target SVM ID will be treated as targeting thereceiving SVM. A request that targets an SVM different from thereceiving SVM may be routed to reach the target SVM by passing through anumber of SVMs and channels in between. For correct handling of arequest, a request can be divided into two parts: a header and a body.The header of the request contains target SVM ID. The header may alsoserve as storage for SVM routers storing routing information and/orinstructions temporary or permanently. For this reason, the headershould use a form, type and format which are supported by all SVMs. Incontrast, the body of the request contains payload (as referred to asdata, e.g., Service ID, Object ID, Method ID, parameters, reply-toinformation, etc.) that are interpreted and processed by the target SVMand are not used for performing routing.

Source Code 1 import java.lang.reflect.Method; 2 importjava.util.HashMap; 3 import java.util.Map; 4 importjava.util.UUID; 5importjava.util.concurrent.ThreadPoolExecutor; 6importjava.util.concurrent.locks.Lock; 7importjavax.swing.SwingUtilities; 8 9 class JavaSVM { 10 11 ThreadPoolExecutorthreadPool; 12  Map associationMap; 13   14  /** 15 * An association represents a virtual object. 16  *Key Supported Values17  *                 18  * “ObjectID” Virtual Object IDs (e.g.,“order”, “product”) 19  * “MethodPolicy” “same-name or “java-interface”20  * “ThreadPolicy” “thread-pool” or “GUI-thread” or “single-threaded”or “load-balancer” 21  * “NativeObjects” an array of one or moreJ avaobjects 22  * “NativeLocks” an array of zero or more Java Lock objects23  */ 24 25  public void registerObject (Map association) { 26  associationMap.put (association.get (“ObjectID”), association); 27  }28 29  public void invokeService (String serviceID, StringreplytoServiceID, Object... args) { 30   Map session = new HashMap ( );31   String[ ]idList = serviceID.split (“.”); 32   session.put(“ObjectID”, idList[0]); 33   session.put (“MethodID”, idList[1]); 34  session.put (Parameters, args); 35   session.put (“ReplyToServiceID”,replytoServiceID); 36   Map association = (Map) associationMap.get(idList[0]); 37   this.identifyNativeMethod (association, session); 38  thisidentifyThreadAndInvoke (association, session); 39  } 40 41 private void identifyNativeMethod (Map association, Map session) { 42  Object firstNativeObject = ((Object[ ]) association.get(“NativeObjects”))[0]; 43   session.put (“RefToNativeObject”,firstNativeObject); 44   if (association.get (“MethodPolicy”).equals(“same-name)) { 45    for (Method method : firstNativeObject.getClass ().getMethods ( )) { 46     if (session.get (“MethodID”).equals(method.getName ( ))) { 47      session.put (“RefToNativeMethod”,method); 48      return; 49     } 50    } 51   }else if (association.get(“MethodPolicy”).equals (“java-interface”)) { 52    return; 53   } 54  }55 56  private void identifyThreadAndInvoke (final Map association,final Map session) { 57   if (association.get (“ThreadPolicy”).equals(“thread-pool”)) { 58    threadPool.submit (new Runnable ( ) { 59    public void run ( ) { 60      JavaSVM.this.invokeAndReply(association, session); 61     } 62    }); 63   }else if(association.get (“ThreadPolicy).equals (“GUI-thread”)) { 64   SwingUtilities.invokeLater (new Runnable ( ) { 65     public void run( ) { 66      JavaSVM.this.invokeAndReply (association, session); 67    } 68    }); 69   }else if (association.get (“ThreadPolicy).equals(“single-threaded”)) { 70    threadPool.submit (new Runnable ( ) { 71    public void run ( ) { 72      Lock firstImplLock = ((Lock[ ])association.get (“NativeLocks”))[0]; 73      firstImplLock.lock ( ); 74     try { 75       JavaSVM.this.invokeAndReply (association, session);76      } finally { 77       firstImplLock.unlock ( ); 78      } 79    } 80    }); 81   } else if (association.get (“ThreadPolicy”).equals(load-balancer)) { 82    threadPool.submit (new Runnable ( ) { 83    public void run ( ) { 84      Object[ ] implObjects = (Object[ ])association.get (“NativeObjects”); 85      Lock[ ] implLocks = (Lock[ ])association.get (“NativeLocks”); 86      while (true) { 87       for(int i = 0; i < implObjects.length; i++) { 88        if(implLocks[i].tryLock ( )) { 89         try{ 90          session.put(“RefToNativeObject”, implObjects[i]); 91         JavaSVM.this.invokeAndReply (association, session); 92         return; 93         }finally{ 94          implLocks[i].unlock (); 95         } 96        } 97       } 98      } 99     } 100    }); 101  } 102  } 103 104  private void invokeAndReply (Map association, Mapsession) { 105   try{ 106    Object implObject = session.get(“RefToNativeObject”); 107    Object[ ] args = (Object[ ]) session.get(Parameters); 108    Object returnValue = null; 109 110    if(association.get (“MethodPolicy”).equals (“same-name”)) { 111     MethodimplMethod = (Method) session.get (“RefToNativeMethod”); 112    returnValue = implMethod.invoke (implObject, args); 113    } else if(association.get (“MethodPolicy).equals (“java-interface”)) { 114    HandlerInterface interfaceImpl = (HandlerInterface) implObject; 115    String methodID = session.get (“MethodID”).toString ( ); 116    returnValue = interfaceImpl.onRequest (methodID, args); 117    } 118119    String replytoServiceID = (String) session.get(“ReplyToServiceID”); 120    if (replytoServiceID != null) { 121    this.invokeService (replytoServiceID, null, returnValue); 122    }123   } catch (Exception error) { 124    // log the error 125   } 126  }127 128  public Token createNewToken ( ) { 129   Token token = new Token( ); 130   token.objectID = UUID.randomUUID ( ).toString ( ); 131 132  Map association = new HashMap ( ); 133   association.put (“ObjectID”,token.objectID); 134   association.put (“MethodPolicy”, “same-name”);135   association.put (“ThreadPolicy”, “thread-pool”); 136  association.put (“NativeObjects”, new Object[ ]{ token }); 137 138  this.registerObject (association); 139 140   return token; 141  } 142} 143 144 interface HandlerInterface { 145  Object onRequest (StringmethodID, Object... args); 146 } 147 148 class Token { 149  StringobjectID = null; 150  boolean ready = false; 151  Object result = null;152  ResultListener listener = null; 153 154  public interfaceResultListener { 155   void onResult (Object result); 156  } 157 158 public String getServiceID ( ) { 159   return objectID + “.setResult”;160  } 161 162  synchronized void setResult (Object... args) { 163  result = args; 164   ready = true; 165   this.notifyAll ( ); 166   if(listener != null) { 167    listener.onResult (result); 168   } 169  }170 171  synchronized boolean isReady ( ) { 172   return ready; 173  }174 175  synchronized Object getResult ( ) throws Exception { 176   if(!isReady ( )) { 177    this.wait ( ); 178   } 179   return result; 180 } 181 182  synchronized void setListener (ResultListenerresultReadinessListener) { 183   listener = resultReadinessListener; 184 } 185 } 186 187 // Code snippet that illustrates usage of token 188Token token =j avaSVM.createNewToken ( ); 189 javaSVM.invokeService(“order.place”, token.getServiceID ( ), “computer”, 1); 190 doubleamount = (Double) token.getResult ( ); 191 javaSVM.invokeService(“order.pay”, null, amount);

1. A method for processing in a computer program a request received by aservice virtual machine (SVM), comprising: receiving a request, whereinthe request includes a reference and a parameter; identifying, based onthe reference a native procedure; invoking the native procedure andproviding the parameter to the native procedure; determining if therequest comprises a target textual identifier and a reply-to serviceidentifier; in an event the request includes the reply-to serviceidentifier: receiving a result from the native procedure, forming areply-to request, the reply-to request including the reply-to serviceidentifier, and the result received from the native procedure, andsending, to the SVM, the reply-to request; in an event the request doesnot include the target textual identifier, or the target textualidentifier is associated with the SVM, processing the received request;in an event the request includes the target textual identifier thatidentifies a neighbor SVM, submitting the request to the neighbor SVM;and in an event the request includes the target textual identifier thatdoes not identify a neighbor SVM, receiving a neighbor SVM textualidentifier, and then submitting the request to the neighbor SVMidentified by the neighbor SVM textual identifier.
 2. The method ofclaim 1, wherein the native procedure is a standalone procedure or aglobal procedure.
 3. The method of claim 1, wherein the native procedureis a method provided by an object.
 4. The method of claim 1, wherein thenative procedure is a method provided by a class.
 5. (canceled)
 6. Themethod of claim 1, wherein the neighbor SVM textual identifier is aresult of the SVM performing a routing algorithm.
 7. The method of claim1, wherein the neighbor SVM textual identifier is a result of the SVMreading a memory configuration.
 8. The method of claim 1, wherein theneighbor SVM textual identifier is a result of the SVM reading aconfiguration file.
 9. The method of claim 1, wherein the neighbor SVMtextual identifier is received by the SVM from outside the SVM.
 10. Themethod of claim 1, wherein the reference includes an object identifierand a method identifier identifying the native procedure.
 11. The methodof claim 10, further comprising identifying a native object based on theobject identifier.
 12. The method of claim 11, further comprisingidentifying a native method in the native object based on the methodidentifier, wherein the native procedure is the native method.
 13. Themethod of claim 12, wherein invoking the native procedure comprisesinvoking the native method.
 14. The method of claim 10, furthercomprising identifying multiple objects based on the object identifier.15. The method of claim 14, further comprising identifying a singleobject from the multiple objects.
 16. The method of claim 15, furthercomprising identifying a native method in the single object based on themethod identifier, wherein the native procedure is the native method.17. The method of claim 11, further comprising allowing only one threadat a time to invoke a method in the native object.
 18. The method ofclaim 1, further comprising: receiving the request using a first thread;and invoking the native procedure using a second thread.
 19. The methodof claim 18, wherein the first thread is asynchronous of the secondthread.
 20. The method of claim 19, wherein the first thread and thesecond thread are two different threads.
 21. The method of claim 20,wherein the first thread and the second thread are the same thread, butare asynchronous to each other due to thread scheduling.
 22. (canceled)23. (canceled)
 24. A method for processing, in a computer program,requests received by a source service virtual machine (SVM), comprising:receiving, by the source SVM, a first request from within the computerprogram, wherein the first request includes at least a first targetreference and a first parameter; if the first request does not comprisea target SVM identifier or the target SVM identifier is associated withthe source SVM, then: identifying, based on the first target reference,a callable programming unit within the computer program, invoking thecallable programming unit and providing the first parameter to thecallable programming unit, and processing, by the source SVM, a nextrequest if the first request does not include a reply-to reference; inan event the first request also includes a reply-to reference: receivinga result from the callable programming unit, wherein the result is basedat least in part on a value of the first parameter, forming a secondrequest, wherein the second request includes a second target referenceand a second parameter, the second target reference is the reply-toreference, and the second parameter is the result received from thecallable programming unit, and sending the second request to the sourceSVM from within the computer program such that the second requestcarries the result received from the callable programming unit to thesource SVM as a subsequent request and the second request is only formedand sent to the source SVM after the callable programming unit generatesthe result for the second request to be processed by the source SVM; andif the first request comprises a target SVM identifier not associatedwith the source SVM, then determining if the target SVM identifier isassociated with a connected service virtual machine and sending therequest to the connected service virtual machine if the target SVMidentifier is associated with the connected service virtual machine. 25.A computer-implemented method for providing a service virtual machine,the method comprising: receiving a request from a caller, the requestcomprising a reference to a virtual service; if the request does notcomprise a target identifier or the target identifier is associated withthe service virtual machine, then invoking a native programming unitassociated with the virtual service; and if the request comprises atarget identifier not associated with the service virtual machine, thendetermining if the target identifier is associated with a connectedservice virtual machine and sending the request to the connected servicevirtual machine if the target identifier is associated with theconnected service virtual machine.
 26. The method of claim 25, wherein:determining if the target identifier is associated with a connectedservice virtual machine comprises determining if the target identifieris associated with a neighbor service virtual machine; and sending therequest comprises sending the request to the neighbor service virtualmachine if the target identifier is associated with the neighbor servicevirtual machine.
 27. The method of claim 25, wherein: determining if thetarget identifier is associated with a connected service virtual machinecomprises seeking routing information that indicates a neighbor servicevirtual machine is in or stores a route to the connected service virtualmachine; and sending the request to the neighbor service virtual machineif the routing information indicates the neighbor service virtualmachine is in or stores a route to the connected service virtualmachine.
 28. The method of claim 25, wherein: determining if the targetidentifier is associated with a connected service virtual machinecomprises determining if the target identifier is associated with aneighbor service virtual machine; sending the request comprises sendingthe request to the neighbor service virtual machine if the targetidentifier is associated with the neighbor service virtual machine; ifthe target identifier is not associated with a neighbor service machine,seeking routing information that indicates a neighbor service virtualmachine is in or stores a route to the connected service virtualmachine; and sending the request to the neighbor service virtual machineif the routing information indicates the neighbor service virtualmachine is in or stores a route to the connected service virtualmachine.
 29. The method of claim 25, further comprising: receiving aresult from the native programming unit associated with the virtualservice; and if the request comprises a reference to a reply-to virtualservice: forming a second request comprising a second target identifierassociated with the reply-to virtual service, if the second targetidentifier is associated with the service virtual machine, then invokinga second native programming unit associated with the reply-to virtualservice, and if the second target identifier is not associated with theservice virtual machine, then determining if the second targetidentifier is associated with a connected service virtual machine andsending the request to the connected service virtual machine if thesecond target identifier is associated with the connected servicevirtual machine.
 30. A method for processing a request received by aservice virtual machine, the method comprising: receiving a request,wherein the request includes a target reference and a parameter;determining if the target reference comprises a service identifier; ifthe target reference does not include the service identifier or theservice identifier is associated with the service virtual machine, then:identifying a native procedure based on the target reference, invokingthe native procedure with the parameter, determining if the requestcomprises a reply-to reference, and in an event the request includes thereply-to reference: receiving a result from the native procedure,forming a reply-to request, the reply-to request comprising the reply-toreference and the result received from the native procedure, and sendingthe reply-to request to the service virtual machine; and if the serviceidentifier is not associated with the service virtual machine,forwarding the request.
 31. The method of claim 30, wherein forwardingthe request comprises submitting the request to a neighbor servicevirtual machine if the service identifier identifies the neighborservice virtual machine.
 32. The method of claim 30, wherein forwardingthe request comprises submitting the request to a router.
 33. The methodof claim 30, wherein forwarding the request comprises receiving aneighbor service virtual machine identifier and submitting the requestto a neighbor service virtual machine identified by the neighbor servicevirtual machine identifier if the service identifier does not identify aneighbor service virtual machine.
 34. The method of claim 33, whereinreceiving the neighbor service virtual machine identifier is receivedfrom a routing algorithm executed by the service virtual machine. 35.The method of claim 33, wherein the neighbor service virtual machineidentifier is received from a memory configuration read by the servicevirtual machine.
 36. The method of claim 33, wherein the neighborservice virtual machine identifier is received from a configuration fileread by the service virtual machine.
 37. The method of claim 33, whereinthe neighbor service virtual machine identifier is received from outsidethe service virtual machine.
 38. The method of claim 30, whereinforwarding the request comprises: if the service identifier identifies aneighbor service virtual machine, submitting the request to the neighborservice virtual machine; if the service identifier does not identify aneighbor service virtual machine, receiving a neighbor service virtualmachine identifier and submitting the request to a neighbor servicevirtual machine identified by the neighbor service virtual machineidentifier; and if the service identifier does not identify a knownservice virtual machine, submitting the request to a router.
 39. Asystem for providing a virtual service to a calling program, the systemcomprising: a target service virtual machine; and a source servicevirtual machine connected to the target service virtual machine, whereinthe source service virtual machine is configured to: receive a requestfrom the calling program, the request comprising a reference to thevirtual service, determine if the request includes a target identifier,if the request does not comprise a target identifier or the targetidentifier is associated with the source service virtual machine, theninvoking a native programming unit associated with the virtual service,and if the target identifier is not associated with the source servicevirtual machine, then determining if the target identifier is associatedwith the target service virtual machine and sending the request to thetarget service virtual machine if the target identifier is associatedwith the target service virtual machine.